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(57) ABSTRACT 

A computing device has a database replica comprised of a 
plurality of records. A synchronization request is provided to 
a further computing device having a further database replica 
which is comprised of a further plurality of records. A 
version table maintains version numbers for each of the 
plurality of records. The version numbers each have a 
maximum size. The maximum size is selectable. The plu- 
rality of records may be synchronized with the further 
plurality of records based upon the version numbers. 
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METHOD AND APPARATUS FOR RANDOM 
UPDATE SYNCHRONIZATION AMONG 
MULTIPLE COMPUTING DEVICES 

FIELD OF THE INVENTION 

The present invention relates in general to memory updat- 
ing and more specifically to update synchronization among 
multiple computing devices. In particular, devices which are 
temporarily connected to the network are update synchro- 
nized with other devices which reside on the network. 

BACKGROUND OF THE INVENTION 

With the rapid advancement of semiconductor, storage 
and display technologies, hand held or mobile devices have 
become increasing versatile and popular. A user may simul- 
taneously posses several of these devices, such as Palm Pilot 
(which is a trademark of IBM Corporation, Armonk ; N.Y.), 
mobile phone, laptop PC, home PC, office workstation, etc. 
A single database, file or document may be multiply repli- 
cated over several of these computing devices. 

A critical issue in this environment is that these multiple 
replicas on the various devices may be updated indepen- 
dently. Furthermore, the update synchronization can occur 
between any pair of devices. Since many of these devices are 
mobile or hand held, they are only occasionally connected 
either to the network or directly to another device. Any 
centralized scheduling on update synchronization will not 
work in this envirornent. Neither will the client-server 
model where each client machine will always perform 
synchronization with a pre-assigned server. Here the appro- 
priate model is the any-to-any synchronization model, where 
any pair of devices can perform synchronization with each 
other at any time. For example, assume an individual has 
four devices: Palm Pilot, Thinkpad (which is a trademark of 
IBM Corporation, Armonk, N.Y.), office workstation and 
desktop PC at home. The individual may want to replicate 
his calendar over all of these devices. On a business trip, he 
may bring the Palm Pilot and Thinkpad with him. He can 
leave the Thinkpad in the hotel and only carry the Palm Pilot 
to his business meeting. When returning to the hotel, he can 
synchronize the Thinkpad with the Palm Pilot which con- 
tains the update he had made during the day. The individual 
can then use the Thinkpad to dial up to the office workstation 
to synchronize with the update made by his secretary on the 
workstation copy. His wife at home can synchronize the 
copy on the home PC with the office workstation so she can 
let him know the weekend schedule. 

This update synchronization issue is different from the 
conventional database update issue among multiple replica 
where most of the devices are always connected^ The 
standard transactional approach is to propagate every update 
to all replica before a transaction can commit. This is 
described, for example, in P. A. Berstein, et al., "Concur- 
rency Control and Recovery in Database Systems", 
Addisi on- Wesley, Reading, Mass. 1987. This update or 
write-all approach can use any serializable concurrency 
control to synchronize access to the multiple copies. A 
variation is to allow for only updating a majority of the 
replica or quorum consensus. Another variation is the lazy 
propagation approach where only one replica is updated by 
the transaction itself, as for example, Y. Breitbart, et al., 
"Replication and Consistency: Being Lazy Helps 
Sometimes", Proc. ACM Symposium on Principles of Data- 
base Systems, 1997, pp. 173-184. In this approach, a 
separate transaction runs on behalf of the original transac- 
tion at each replication site at which update propagation is 
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required. Consistency can be ensured by directing all 
updates to a primary copy and employing appropriate con- 
currency control. 
The issue considered is also different from that in a client 

5 server environment. In a client server environment, although 
the client can stay mostly unconnected, it always has a 
specific server to synchronize to. See for example, in L. 
Kawell, et al., "Replicated Document Management in a 
Group Communication System", in Groupware: Software 

1(J for Computer-supported Cooperative Work, pp. 226-235, 
IEEE Computer Society, 1992, and K. Moore, "The Lotus 
Notes Storage System", Proc. ACM SIGMOD 95 
conference, pp. 427-428 on the replication approach in 
Lotus Notes. In this approach, the time of last modification 
is kept with each record (or document) of a replica. Only the 

15 records modified since the last synchronization are 
exchanged during the synchronization. Another approach as 
used by Palm Pilot is to maintain a dirty bit on each modified 
record. When a record is modified, the dirty bit is turned on. 
During synchronization, all modified records are exchanged 

20 and the dirty bits are reset to zero. For example, R. Riggs, 
"MNCRS Data Synchronization Architecture Document", 
www.oadg.or.jp/activity/mncrs/dsync/arch/ 
datasyncarch.html, specifies a framework for data synchro- 
nization between mobile network computers, such as Palm 

25 Pilot, and its servers or peers. 

In the environment considered here, a device can request 
sync with any other device. There is no designated sync 
server for a device. A straightforward approach to do any- 
to-any sync is to maintain a local time-stamp on update by 

30 each device on each record, e.g., device 1 updates record 1 
at 9:50 am, Jun. 23, 1997 and device 2 updates the same 
record at 10:50 am, Jun. 25, 1997. Since the update time is 
based on local device time, no global time synchronization 
would be required. The problem with this time-stamp 

35 approach is that the number of bits required to represent the 
time-stamp is sizable. For example, a time stamp with 
year/month/date/time can require more than 32 bits. As the 
number of records and devices increases, it will cause 
considerable delay to perform the synchronization, espe- 

40 cially in a low bandwidth environment such as a phone line. 
An alternative approach is the local counter approach that 
maintains a local counter on each device, where every time 
a record of a database (or file) is updated (or iaserted/ 

45 deleted) by a device, the local counter for the device which 
performed the update is incremented by one, and assigned to 
that file as a version number. For example, D. S. Parker, et 
al., "Detection of Mutual Inconsistency in Distributed 
Systems", in IEEE Trans. On Software Engineering, Vol. 

5Q SE-9, No. 3, May, 1983, pp. 240-247, provides a means to 
detect version conflict through maintaining the version num- 
bers from each system or device to a file. This version 
number can still become an arbitrarily large number. 

SUMMARY OF THE INVENTION 

55 A computing device has a database replica comprised of 
a plurality of records. A synchronization request is provided 
to a further computing device having a further database 
replica which is comprised of a further plurality of records. 
A version table maintains version numbers for each of the 

60 plurality of records. The version numbers each have a 
maximum size. The maximum size is selectable. The plu- 
rality of records may be synchronized with the further 
plurality of records based upon the version numbers. 

65 BRIEF DESCRIPTION OF THE DRAWINGS 

FIG. 1 is a block diagram which depicts an example of an 
overall architecture of a computing device. 
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FIGS. 2(a), 2(b) and 2(c) depict examples of version Past update activities are tracked so that independent 

tables which contain update information for exchange dur- updates from the different devices to the different replica of 

ing synchronization to identify for each record which device the same database can be consolidated. This is described 

has the more up-to-date version of that record. below. 

FIG. 3 is a flowchart diagram which illustrates exemplary 5 Consider the following example. Device 1 creates a 

execution of computing device logic. database with 5 records. Then, devices 2 and 3 obtain a copy 

FIG. 4 is a flowchart diagram which illustrates exemplary of that database from device 1. Afterwards, device 1 makes 

operation of the sync initiator. an update to record 1, and three updates to record 2. Device 

FIG. 5 is a flowchart diagram which illustrates exemplary 2 makes an update to record 3 and device 3 makes an update 

operation of the sync handler 30 t0 record 5 - D ev *ce 4 then gets a copy of the database from 

FIG. 6 is a flowchart diagram which illustrates exemplary device 3 and u makcs an u P da * t0 re ™ rd Now ' devi f e * 

execution of the version comparison routine. requests synchronization with device 1. The issue is which 

a , .„ , devices have the more up-to-date version of each record. In 

FIG. 7 is a flowchart diagram wh.ch illustrates exemplary ^ deyice 4 has ^ mQre . t0Klate V6Isjon of records 

execution of the update sync routine. A , - , . A , tI _ r . . . c 

r J 15 4 and 5, while device 1 has the more up-to-date version of 

FIG. 8 is a flowchart diagram which illustrates exemplary records x and 2 . So during the synchronization, device 1 
operation of a replica initiator. needs t0 updale records 4 and 5> while device 4 needs t0 

FIG. 9 is a flowchart diagram which illustrates exemplary update records 1 and 2. 
operation of a replica handler. Consider another case where device 3 requests synchro- 

FIG. 10 is a flowchart diagram which illustrates exem- 20 nization with device x ^ ioTQ device 4 During the sync h ro . 
plary operation of a record modifier. nization between devices 1 and 3, device 1 would need to 

FIG. 11 is a flowchart diagram which illustrates a garbage update record 5, and device 3 would need to update records 
collection routine. 1 and 2. When device 4 requests synchronization with 

FIG. 12 is a flowchart diagram which illustrates a local device 1 later, device 1 only needs to update record 4 in 
marked routine. 25 contrast to the original case. Device 4 still needs to update 

FIG. 13 is a flowchart diagram which illustrates an records 1 and 2. 
example of a phase one advancement checking routine. A third case will be that continuing from the second case, 

FIG. 14 is a flowchart diagram which illustrates an device 4 requests synchronization with device 2 before it 
example of a phase two advancement checking routine. 30 requests sync with device 1. During sync between devices 4 

FIG. 15 is a flowchart diagram which illustrates an and 2 > device 4 updates record 3 and device 2 updates 
example of a remote mark routine. rec °' ds * and 5 ' °* the ^sequent sync between devices 4 

and 1, device 4 needs to update records 1 and 2, while device 
DETAILED DESCRIFHON OF THE 1 needs to update records 3 and 4. 

INVENTION ^ From the above examples, it can be, seen that in order to 

It is desirable to use a compact version number per device perform the synchronization correctly, one mast know what 
for each record which takes just a few bits (say 2 or 4) to updates from each of the devices are captured in each record, 
represent the version of the record, while allowing for FIGS. 2(a), 2(b) and 2(c) depict examples of version 

multiple computing devices to maintain replica of data tables which contain the update information for exchange 
objects and perform updates independent of the other rep- 40 during synchronization to identify for each record which 
lica. The synchronization with other replica is desirably device has the more up-to-date version of that record. Each 
carried out in any arbitrary order efficiently (i.e., with low database has a version table and each of its records has an 
bandwidth requirement) in a pair- wise fashion as these entry in the version table. The entry consists of two parts, 
devices are most disconnected from each other. This com- The first part is the record ID and the second part is the 
pact representation can reduce the bandwidth requirement 45 version list. The version list includes a device-version com- 
substantially by an order of magnitude. ponent for each device with a replica of the database. It has 

FIG. 1 is a block diagram which depicts an example of an the form of ((dl, vl), (d2, v2), . . . , (dk, vk)), where dk 
overall architecture of a computing device. The computing represents the i-th device ID and its version number vi. The 
device can be, for example, a PC, a hand held device (such number of bits required to represent the version number 
as a Palm Pilot, a smart phone, etc.), a workstation (such as 50 decides the size of the version table. Since the content of the 
RS 6000), etc. ■ ~ version table is communicated during-synchronization, a 

The computing device can include a CPU 150, memory method is provided that can use a compact version number 
145 such as RAM, and storage devices 160 such as DASD. which consists of only a small number of maximum bits, say 
The memory 145 stores the client logic 140 (with details 2 to 4 bits. This number (or integer) can be specified by the 
depicted in FIG. 2) preferably embodied as computer 55 user or system administrator. 

executable code which may be loaded from DASD 160 into As shown in FIG. 1, version manager 350 is included, 

memory 145 for execution by CPU 150. Many hand held Version number manager 350 includes logic which may be 
devices store all information in memory without any storage invoked, for example, by the user or system administrator, 
devices. The computing device logic 140 includes a sync Version number manager 350 accomplishes configuration of 
initiator 320 (with details depicted in FIG. 4), a sync handler 60 the size of the compact version number. The size of the 
330 (with details depicted in FIG. 5), a replica initiator 335 compact version number may be separately configured for 
(with details depicted in FIG. 8), a replica handler 340 (with each computing device that is being used. For example, 
details depicted in FIG. 9), a record modifier 315 (with devices that do not have a large memory (e.g., a Palm Pilot) 
details depicted in FIG. 10) and a version number manager may be set to have a compact version number with a size of, 
(described below). It also maintains a version table 180 and 65 for example, 2 to 4 bits. By contrast, large devices (such as, 
a database 170 which can either reside in disk 160 or in main for example, PCs) may be configured to have compact 
memory 145. version numbers with a large size (e.g., 4 bytes). 
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The compact version number is used to track updates onto the two replicas are in conflict, i.e., both devices have made 

a particular record. The compact version number does not updates to the same record. In that case, the sync handler 

reflect updates to other records. For example, the compact routine only identifies the record in conflict. The conflict 

version number, vi, is incremented by one each time the resolution is resolved at the application level. For example, 

record is updated by the i-th device, di. Since the compact 5 consider a calendar application. If the very same event gets 

version number only consists of a few number of bits, for the rescheduled in two different time slots via two different 

often updated records, their compact version numbers can devices (presumably by two different persons), the sync 

overflow and a method is provided to address this issue in server desirably flags the two conflicting records and lets the 

the record modify routine depicted in FIG. 10. user or application resolve the conflict. If there is no conflict, 

Since each device can independently insert a new record, 1Q the sync handler 330 uses the version list to determine which 

the record ID consists of two components the device ID copy or version of a record is the up-to-date version to 

creating the record and a unique sequence number assigned replace the other copy of the record. The sync handler 330 

to that device. For example, record (2.1) represents the first creates three separate lists of records: send-list, receive-list 

record created by device 2 and record (1.5) represents the 5** a nd conflict-list. Send-list includes the record IDs of those 

record created by device 1. Certainly, as the number of ^ records where the local device has the more up-to-date 

devices having a replica changes over time, the number of version, while the receive-list includes the record IDs of 

components in the version list also changes accordingly. mose records where the remote device has the more up-to- 

When a device inserts a new record, that record is given date version. The conflict list includes the record IDs of 

a version number of 1. When a device simply receives (for those records where the local and remote devices have made 

the first time) a replication of a record, the receiving device 2Q conflicting updates. 

gives the newly received record a version number of 0. FIG. 4 is a flowchart diagram which illustrates exemplary 
Consider an example. Start with device 1 which creates a operation of the sync initiator 320. At step 405, the corn- 
database with two records, record 1.1 and record 1.2. Their puting device initiating the sync sends the sync request 
version numbers are all (1,1) as shown in FIG. 2(a). Now, together with the version table of the database to the target 
device 2 comes and requests a replica. The version list will 25 device. It then waits for the response at step 410. When the 
now become ((1,1)(2,0)) for both devices, as shown in FIG. response arrives, it checks at step 415 whether the send-list 
2(b). If device 2 inserts a new record, it will have a record is non-empty. If so, at step 420, for each record ID in the 
ID (2.1) and version list ((1,0X2,1)). If it updates record send-list, it updates the record value and its version list. At 
(1.2), the record will have a new version number ((1,1)(2, step 425, it checks whether the receive-list or conflict-list is 
1)). If device 1 updates record (1.1), it will have a new 30 non-empty. If so, at step 430, it sends all records indicated 
version number ((1,2)(2,0)). If it inserts a new record, the on the receive-list and conflict-list to the target device. At 
record will have an ID (1.3) and a version number ((1.1) step 435, it checks if the conflict-list is non-empty. If so, at 
(2.0)). If the two devices sync with each other, the resulting step 440, it will invoke the conflict handler routine which, as 
version is shown in FIG. 2(c). mentioned before, is only recording the conflict for the 

Those skilled in the art will also appreciate that there are 35 application to resolve the conflict, 

different ways to represent the record ID. One alternative FIG. 5 is a flowchart diagram which illustrates exemplary 

implementation is not to directly include the device ID in the operation of the sync handler 330. At step 505, the target 

record ID, but to use separate tables or table partition to device receives the sync request with the version table of the 

represent the records created from each device. Similarly, database. It then examines each of the record IDs indicated 

there are many alternative ways to implement the version 40 in either the local version table or the remote (requesting 

list. One optimization is to eliminate all devices which have device) version tables. At step 510, if there is no more 

not yet made any updates to a record from its version list. unexamined record IDs in either version tables, the update 

That is to say, in FIG. 2(b), the version list for (1,1) is now sync routine in FIG. 7 is invoked at step 550. Otherwise, at 

reduced to (1,1). Another alternative is not to keep the device step 515, the next not yet examined record in the two version 

ID in the list, but to keep a table- wise order on the devices. 45 tables is selected. At step 520, it is checked if the selected 

For example, if the table-wise order on the devices is (device record ID appeared in both version tables. If so, at step 525, 

1, device 2, device 3), then a more compact representation the version comparison routine in FIG. 6 is invoked, 

of the version list (1,1)(2,1)(3,0) is (1,1 ,0). Also, if a device Otherwise, at step 535, it is checked if the selected record ID 

has not yet made any update to any of the records, it can also appeared only in the local version table. If so, at step 540, 

be omitted from the version list. 50 the record ID and its version list is added to the send-list. 

FIG. 3 is a flowchart diagram which illustrates exemplary Otherwise, the record ID only appears in the remote version 

execution of computing device logic 140. In step 305, the table. At step 545, the record ID and its version list is added 

device waits for input. Depending upon the type of input, the to the receive-list. 

appropriate routine will be invoked. The sync initiator 320 FIG. 6 is a flowchart diagram which illustrates exemplary 
is used to request database (or any data object) synchroni- 55 execution of the version comparison routine in FIG. 5. At 
zalion with another computing device. The sync handler 330 step 605, the local version number and the remote version 
handles the sync request from another device to synchronize number on every device are compared. If the devices 
the two replica. The replica initiator 335 is used to request included on the two version lists are not the same, each 
a replica of a database which the device does not yet have version list will be augmented to include the missing devices 
a copy, while the replica handler 340 is to provide the 60 with the version number set to zero during the comparison, 
requesting device with a copy of the database. The record The local version table can be immediately updated, while 
modifier 315 is used to handle the database modification of the device IDs of the missing devices form the remote 
the local replica which can be a record update, deletion or version table can be included in the send-list for the request- 
insertion. A feature of the record modifier 315 is the way it ing device to update its version table later. If the version 
updates the version list of the modifier record. 65 number is not the same on every device, it is further 
The sync handler 330 handles the sync request based on checked, at step 610, if the local version number is larger 
the version lists to determine whether versions of a record in than or equal to the remote version number for every device. 
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If so, at step 620, the record ID and its version list are added upon updates. An alternative method is to have the version 

to the send-list. If so, at step 615, it is checked whether the number only capture the number of sync intervals with 

local version number is smaller than or equal to the remove updates to the corresponding record, instead of the number 

version number for each device. If so, at step 630, the record of updates to the record, where a sync interval is the time 

ID and its version list are added to the receive-list. 5 interval between two consecutive sync points (to any 

Otherwise, at step 625, the record ID and its version list are devices). That is to say under this alternative method, 

added to the conflict-list. multiple updates within a single sync interval by a device 

FIG. 7 is a flowchart diagram which illustrates exemplary will only cause the version number to be incremented by 1. 

execution of the update sync routine in FIG. 5. At step 705, Only the first update to a record since the last synchroniza- 

it is checked whether the send-list or conflict-list is non- 1Q tion will cause the version number (associated with the local 

empty. If so, at step 710, the nonempty send-list and device) to increase. This would reduce the number of times 

conflict-list will be augmented with the corresponding a version number exceeds its maximum value, 

record for each record ID in the lists to be sent to the Because each device can modify any records 

requesting device. At step 715, it is checked whether the independently, the version list of a deleted record is desir- 

receive-list is non-empty. If so, at step 725, the receive-list 1$ ably kept after the record deletion. Otherwise, it would not 

is sent to the requesting device. At step 730, the target device be able to differentiate during synchronization whether the 

waits for the response from the requesting device. At step other device has an older version or the deleted record or 

720, if the conflict-list is non-empty, execution proceeds to conflicting version of the deleted record, 

step 730 to wait for the response. Upon receiving the To eliminate storage waste, garbage collection can be 

response, at step 740, for each record ID in the receive-list, 2Q done to recover storage occupied by records that have been 

the record and its version list get updated. At step 745, if the marked for deletion. In the preferred embodiment, a method 

conflict-list is non-empty, the conflict handler routine is is provided using a three phase deletion protocol. The record 

invoked at step 750. As will be explained later with refer- deletion protocol uses two vectors for bookkeeping. A phase 

ence to FIG. 12, at step 760, the garbage collection routine i vector is a bit vector to track the devices that have been 

can be invoked to clean up the space occupied by deleted 25 notified on the record deletion. At the end of phase 1, every 

records. device with a copy of the database has been notified that the 

FIG. 8 is a flowchart diagram which illustrates exemplary record is marked for deletion. A phase 2 vector is a bit vector 

operation of replica initiator 335. At step 805, a computing to track the devices that are aware of the fact that all devices 

device sends a replica request of a database to a target with a copy of the database have been notified that the said 

device. At step 810, the computing device waits for the 30 record is marked for deletion. All devices will have deleted 

response. At step 820, the computing device receives the both the version list of the record and the phase 1 vector by 

database replica and its version table. the end of phase 2. In phase 3, the devices can now delete 

FIG. 9 is a flowchart diagram which illustrates exemplary the phase 2 vector. For a device in phase 3 on a deleted 

operation of replica handler 340. At step 910, the device record, there is no longer any bookkeeping (such as phase 1 

receives a new replica request for a database. At step 920, 35 or phase 2 vector) maintained on the deleted record. All 

the device updates the version table by adding to the version storage space is recovered on the said device for that record, 

list of each record an additional component (dk, vk), where By the end of phase 3, the phase 2 vector of the record is 

dk is the device ID of the requesting device, and vk is set to deleted from all devices. 

zero. At step 910, the database and its version table are sent Those skilled in the art will also appreciate that alternative 

to the requesting device. 40 ways can be used to implement the phase 1 and phase 2 

FIG. 10 is a flowchart diagram which illustrates exem- vectors. In the preferred embodiment, the phase 1 and phase 

plary operation of the record modifier 315. There are, for 2 vectors are considered to be part of the version table in 

example, three different ways to modify a database: update FIG. 2. In addition to the two columns in the version table, 

a record, delete a record and insert a new record. At step a third column can be added to include a pointer to the phase 

1005, it is checked if the database modification request is to 45 1 or phase 2 vector. One pointer suffices as a record can only 

update a record. If so, at step 1010, the record value is be in phase 1 or phase 2 and at any given time, at most one 

updated. At step 1015, the version number associated with of the vectors is needed. Alternatively, a separate deletion 

the local device is incremented by 1 (for example). At step list can be maintained for all records marked for deletion 

1020, it is checked for overflow, i.e., if the version number with a pointer to their phase 1 or phase 2 lists, 

exceeds its maximum allowed value (e.g., if 4 bits are 50 In the preferred embodiment, after a record is marked for 

allocated to represent the version number, the maximum deletion, a phase 1 vector is desirably created. This step is 

allowed value will be 15). If so, an overflow method (steps desirably added to steps 1030 and 1040 depicted in FIG. 10 

1025 and 1030) is invoked. At step 1025, a new record is after the record has been marked for deletion. The record 

created with a new record ID and the same record value as itself can in fact be deleted but its version list is desirably 

the updated record. The version list will be the same as the 55 kept. During subsequent sync, the phase 1 vector is copied 

updated record except that the version number is set to zero to other devices with the bit corresponding to the already 

for the target device. At step 1030, the original record is notified devices turned on. When the last known device with 

marked as a deleted record. At step 1035, it is checked if the a copy of the database gets notified on the deletion during 

database modification request is to delete a record. If so, at the sync operation, the two synchronizing devices can 

step 1040, the record is marked as a deleted record. 60 actually delete their phase 1 vectors, create the phase 2 

Otherwise, the request is a record insertion. At step 1060, a vectors (with the bits corresponding to the two devices 

new record is inserted into the database with a version list turned on) and enter into phase 2. During phase 2, a device 

created in the version table. The version number on each checks whether any new replica has been created during 

device is initialized to zero except for the local device which phase 1. If so, it adds the new device to the list of devices 

is set to one. 65 on the phase 2 vector. During phase 1, if a new device 

Those skilled in the art will also appreciate that there are requests a replica from a device which already marked the 

alternative ways to increment the compact version number record for deletion with an associated phase 1 vector, the 
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new replica will also indicate the record is marked for the local version list, it is addressed in step 625. At step 

deletion with an appropriate phase 1 vector created. Thus, 1230, the phase 1 advancement checking routine depicted in 

even if a new replica created during phase 1 may not be FIG. 13 is invoked. At step 1240, it is checked whether the 

included in the phase 1 vector of some of the devices, it does record is considered to be in either phase 1 or phase 2 in the 

not pose a problem. 5 remote device, while it is considered to be in phase 2 in the 

Consider an example with three devices. After device 1 local drive. If so, at step 1245, the phase 2 vector is updated, 

has sync with device 2, a new device, device 4, requests a If the record is also in phase 2 in the remote device, the new 

replica from device 1. Device 2 then requests sync with phase 2 vector will be the union of the two phase 2 vectors 

device 3. The two devices, not being aware of the existence of the local and remote devices. Otherwise, it will be the 

of device 4, will enter into phase 2. Since device 4 also 10 local phase 2 vector with the additional bit corresponding to 

marks the record as deleted, the condition for entering into *e remote device turned on. At step 1250, the phase 2 

phase 2 is still satisfied. Unfortunately, the phase 1 vector of advancement checking routine is invoked. At step 1260, the 

some of the devices may only indicate 3 devices. This will phase 2 vector is deleted. This corresponds to entering the 

be addressed during phase 2. During phase 2, when the other tnird P hase of the record deletion process as the remote 

device (say device 2) has sync with device 1, it will find out 15 devic ^ is already in phase 3. 

that an additional device has obtained a replica and augment FIG. 13 is a flowchart diagram which illustrates an 

its phase 2 vector. Thus, replica creation during phase 1 does example of the phase 1 advancement checking routine of 

not pose a problem. Similarly, during phase 2, the device FIG. 12. At step 1305, it is checked whether all devices have 

with a new replica is also desirably included in the deleting their corresponding bits turned on in the phase 1 vector of 

process. During phase 2, if a new device makes a request for 20 the record. If so, at step 1310, the phase 1 vector is deleted, 

a replica, the new replica will also include information on The deletion process of the record now enters into phase 2. 

the deleted record, specifically the phase 2 vector. At step 1310, a phase 2 vector is created for the record with 

During phase 2, synchronization will lead to the synchro- the bits corresponding to the two synchronizing devices 

nizing devices deleting the phase 1 vector and updating the turned on. 

phase 2 vector. When all the devices have gone through 1S FIG. 14 is a flowchart diagram which illustrates an 

phase 2, the phase 2 vectors can be deleted. For a device with example of the phase 2 advancement checking routine in 

a partially specified phase 2 vector, it will delete the vector FIG. 12. At step 1410, it is checked whether all devices have 

and enter into phase 3 during sync, if the other device has their corresponding bits turned on in the phase 2 vector of 

neither the phase 1 nor the phase 2 vector for that record. If the record. If so, at step 1420, the phase 2 vector is deleted, 

the other device has a phase 1 vector for the record, that 30 The deletion operation of the record now enters into phase 

device will enter into phase 2 and the phase 2 vectors of both 3. 

devices get updated to reflect the change. If the other device FIG. 15 is a flowchart diagram which illustrates an 

has a phase 2 vector, both devices should update their phase example of the remote marked routine. At step 1505, it is 

2 vectors to be the union of the two. checked if that record is in phase 1 of the deletion process 

FIG. 11 is a flowchart diagram which illustrates the 35 at the remote requesting device. If so, this corresponds to the 

garbage collection routine of FIG. 7. At step 1105, all case that while a record is in phase 1 of the deletion process 

records that have been marked for deletion in the local at the remote requesting device, it is not yet marked as a 

version table are identified. For each of these records, at step deleted record in the local device. At step 1510, a phase 1 

1110, the local marked routine depicted in details in FIG. 12 vector with an additional bit corresponding to the local 

is invoked. At step 1120, all records that have been marked 40 device turns on. An exception is that if the remote version 

for deletion in the remote version table are identified. For list is in conflict with the local version list, it is addressed in 

each of these records, at step 1125, the remote marked step 625. At step 1520, the phase 1 advancement checking 

routine depicted in details in FIG. 13 is invoked. At step routine in FIG. 13 is invoked. It is noted that at step 1505, 

1140, the phase 1 and phase 2 vectors that need to be updated if the record is in phase 2 at the remote site, it means that the 

(by the remote device) are sent to the remote device. When 45 local sil e is already entered into phase 3 with the phase 2 

the remote device receives the updated phase 1 and phase vector deleted. No further step needs to be done at the local 

vectors, it will update its phase 1 and phase 2 vectors site. The remote site would need to delete the phase 2 vector 

accordingly. to enter into phase 3 when it received all the updated phase 

FIG. 12 is a flowchart diagram which illustrates the local 1 and phase 2 vectors for all deleted records from the local 

marked routine. At step 1205, it is checked if the record is 50 device. 

considered to be in phase 1 by the local device. If so, at step Those skilled in the art will also appreciate that although 

1210, it is checked whether the record is considered to be in the preferred embodiment of the present invention only has 

phase 2 by the remote device. If so, at step 1215, the phase the version list attached to each record, the approach can be 

1 vector is deleted and a phase 2 vector is created for the straightforwardly generalized to a hierarchical approach of 
record in the local device. This is to recognize that the 55 attaching a version list to the whole database or a partition 
deleted record is now in phase 2. This newly created phase of the database. The advantage of the hierarchical approach 

2 vector will be the same as the remote phase 2 vector for is as follows. First of all, it can save the amount of 
that record with the exception that the bit position corre- information exchange, or the communication bandwidth 
sponding to this device will not be turned on. At step 1220, requirement. At sync time, the sync initiator wiU is send the 
the phase 2 advancement checking routine depicted in FIG. 60 version list of the database (instead of the version table) to 
14 is invoked. At step 1225, the phase 1 vector for the local the target server. If the two version lists of the database are 
device is updated. Specifically, if the remote device is in the same, the two databases are in sync. No further exchange 
phase 1 , the new phase 1 vector is not the union of the phase of information is required. Otherwise, the version table of 
1 vectors of the two devices. If the remote device has not the requesting device is desirably sent to the target device as 
marked the record for deletion, the bit corresponding to the 65 before. 

remote device is now turned on in phase 1 vector. The Although the invention is illustrated and described herein 

exception is that if the remote version list is in conflict with with reference to specific embodiments, the invention is not 
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intended to be limited to the details shown. Rather, various 
modifications may be made in the details within the scope 
and range of equivalents of the claims and without departing 
from the invention. 

What is claimed is: 5 

1. A method of synchronizing a plurality of computing 
devices each containing respective database replicas, each of 
said replicas having respective records, said method com- 
prising the steps of: 

a) configuring a maximum size, in bits, for a version JQ 
number, said maximum size separately configurable for 
each of said computing devices; 

b) maintaining, for each of said computing devices, said 
version numbers for each of said respective records, 
said version numbers having said maximum size; 

c) transmitting a synchronization request between said 
computing devices; and 

d) synchronizing said computing devices so that said 
respective data base replicas have common records 
based upon said version numbers respectively main- 
tained for said computing devices. 20 

2. A method of synchronizing a plurality of computing 
devices according to claim 1, wherein said version numbers 
for a first of said computing devices is maintained in a first 
list and said version numbers for a second of said computing 
devices is maintained in a second list. 25 

3. A method of synchronizing a plurality of computing 
devices according to claim 2, wherein said first list and said 
second list indicate respective records which correspond and 
are different versions, and, during synchronizing, at least one 

of said first of said computing devices and said second of 30 
said computing devices are updated so that the first of said 
computing devices and the second of said computing 
devices have respective records which correspond and have 
the same versions. 

4. A method of synchronizing a plurality of computing 35 
devices according to claim 2, wherein during synchronizing 

at least one of said first list and said second list are updated 
so that said first list and said second list indicate respective 
records which correspond to each other. 

5. A method of synchronizing a plurality of computing 
devices according to claim 1, wherein a respective one of 40 
said version numbers is incremented when a respective one 

of said devices updates a respective one of said records. 

6. A method of synchronizing a plurality of computing 
devices according to claim 2, wherein during synchronizing, 
one of said records is deleted from one of said first of said 45 
computing devices and said second of said computing 
devices so that the first of said computing devices and the 
second of said computing devices have the same corre- 
sponding records. 

7. A method of synchronizing a plurality of computing 50 
devices according to claim 6, wherein storage space occu- 
pied by said deleted one of said records is subjected to 
garbage collection. 

8. A method of synchronizing a plurality of computing 
devices according to claim 7, wherein if said respective one 55 
of said version numbers is incremented to a maximum value, 
then a new record is created and said respective one of said 
records is deleted. 

9. A method of synchronizing a plurality of computing 
devices according to claim 1, wherein one of said version 60 
numbers is incremented by a fixed increment regardless of 
number of updates to said record corresponding to said one 

of said version numbers between successive synchroniza- 
tions to said computing device having said record. 

10. A method of synchronizing a plurality of computing 65 
devices according to claim 1, wherein a respective further 
version number is assigned each of said database replicas. 
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11. A method of synchronizing a plurality of computing 
devices according to claim 1, wherein step d) is preceded by 
the step of attempting synchronization of said computing 
devices based upon said respective further version number 
of each of said plurality of computing devices. 

12. A method of synchronizing a plurality of computing 
devices according to claim 1, wherein one of said version 
numbers is maintained both locally to a respective comput- 
ing node and remotely therefrom, and wherein said locally 
and remotely maintained one of said version numbers arc 
compared to determine if a conflict exists. 

13. A method of synchronizing a plurality of computing 
devices according to claim 7, wherein garbage collection 
includes the steps of: 

a) notifying each of said devices to delete said record; 

b) notifying each of said devices that each of said devices 
has successfully been notified to delete, said record; and 

c) notifying each of said devices that step b) has been 
successfully completed. 

14. A method of synchronizing a plurality of computing 
devices according to claim 1, wherein said maximum size 
for each of said computing devices is different. 

15. A method of synchronizing a plurality of computing 
devices according to claim 1, wherein said maximum value 
is an integer. 

16. A computing device, one of a plurality of computing 
devices, having a database replica, said database replica 
comprising a plurality of records, said computing device 
comprising: 

request means for providing a synchronization request to 
a farther computing device having a further database 
replica comprised of a further plurality of records; 

version table means for maintaining version numbers for 
each of said plurality of records, said version numbers 
each having a maximum size, in bits; 

version number manager means for configuring said 
maximum size, said maximum size separately config- 
urable for each of said computing devices; and 

synchronization means for synchronizing said plurality of 
records with said further plurality of records based 
upon said version numbers. 

17. A computing device according to claim 16, wherein 
said version numbers are integers. 

18. A computing device, one of a plurality of computing 
devices, having a database replica, said database replica 
comprising a plurality of records, said computing device 
comprising: 

request means for providing a synchronization request 
_ . between said computing devices; .__ _ _ .. 

version table means for maintaining version numbers for 
each of said plurality of records in each of said com- 
puting devices, said version numbers each having a 
maximum size, in bits; 

version number manager means for configuring said 
maximum size, said maximum size separately config- 
urable for each of said computing devices; and 

synchronization means for synchronizing said plurality of 
records in each of said computing devices based upon 
said version numbers. 

19. A plurality of computing devices according to claim 
18, wherein said maximum size for each of said computing 
devices is different. 

20. A plurality of computing devices according to claim 
18, wherein said version numbers for a first of said com- 
puting devices is maintained in a first list and said version 
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numbers for a second of said computing devices is main- version numbers for a first of said computing devices in a 

tained in a second list. first list and said version numbers for a second of said 

21. A plurality of computing devices according to claim computing devices in a second list. 

20, wherein said first list and said second list indicate 28. An article of manufacture as recited in claim 27, 

respective records which correspond and are different 5 wherein said first list and said second list indicate respective 

versions, and, during synchronizing, at least one of said first records which correspond and are different versions, the 

of said computing devices and said second of said comput- computer readable program code means in said article of 

ing devices are updated so that the first of said computing manufacture further comprising computer readable program 

devices and the second of said computing devices have means for causi a com tQ effect dati of ^ 

respective records which correspond and have the same 10 secQnd of said computing devices so thal the firsl of Mid 

versions. _ computing devices in the said second of computing devices 

22. A plurality of computing devices according to claim . r . , , , , r , * 

™ l j u • *i . e ■ j « .i- * have respective records which correspond and have the same 

20, wherein during synchronizing at least one of said first list r , . , . . r 

and said second list arc updated so that said first list and said ve ™ on A s dunn S synchronizing. 

second list indicate respective records which correspond to 15 29 P ro e rara stora S e dev f ice readable b V mac ^ ne > lan " 

each other S*kly embodying a program of instructions executable by the 

23. A plurality of computing devices according to claim machine to perform method steps for synchronizing a plu- 
18, wherein a respective one of said version numbers is rality of computing devices each containing respective data- 
incremented when a respective one of said devices updates base replicas, each of said replicas having respective 
a respective one of said records during synchronizing. 20 records, said method comprising the steps of: 

24. A plurality of computing devices according to claim a ) configuring a maximum size, in bits, for a version 
20, wherein during synchronizing, one of said records is number, said maximum size separately configurable for 
deleted from one of said first of said computing devices and eacn 0 f sa j d computing devices; 

said second of said computing devices so that the first of said b) maintainingj for each of said computing devices, said 

computing devices and the second of said computing 25 versioQ Qumbers for each of said respective records, 

devices have the same corresponding records. said version Qumbers having said maximum ^ 

25. A plurality of computing devices according to claim x . . . . . 4 . 

23, wherein if said respective one of said version numbers c > t^nsmittmg a synchronization request between said 

is incremented to a maximum value, then a new record is computing e vices, an 

created and said respective one of said records is deleted. 30 <*) synchronizing said computing devices so that said 

26. An article of manufacture comprising a computer respective data base replicas have common records 
useable medium having computer readable code means based u P on said version numbers respectively main- 
embodied thereon for synchronizing a plurality of comput- tained for said computing devices. 

ing devices each containing respective database replicas, 30 - A program storing device as recited in claim 29, 

each of said replicas having respective records, the computer 35 wherein said version numbers for a first of said computing 

readable program code means in said article of manufacture devices is maintained in a first list and said version numbers 

comprising computer readable program code means for ^ a s^ 01 ^ of said computing devices is maintained in a 

causing a computer to effect: second list. 

a) configuring a maximum size, in bits, for a version u 31 A Pfogram stormg device as recited in claim 30, 
number, said maximum size separately configurable for « where ' n sa ' d J* lis « and f ld f cond !*< indicate res P ecl,v ? 
each of said computing devices; ? cords wh "; h «*"*P°° d «"> «« d '^! vemons > and 

_ , . . . . , durmg synchronizing, at least one of said first of said 

b) maintaining, for each of said computing devices, said computing devices and said ^cond of said computing 
version numbers for each of said respective records, device§ are updated SQ that the first of said computing 
said version numbers having said maximum size; ^ devices and the second of said compuling devices have 

c) transmitting a synchronization request between said respective records which correspond and have the same 
computing devices; and versions. 

d) synchronizing said computing devices so that said 32. A method of synchronizing a plurality of computing 
respective data base replicas have common records devices according to claim 1, wherein at least one of said 
based upon said version numbers respectively main- 50 computing devices is a hand held device. 

tained for said computing- devices. 33. A plurality of computing devices according to claim 

27. An article of manufacture as recited in claim 26, the 18, wherein at least one of said computing devices is a hand 
computer readable program means in said article of manu- held device. 

facture further comprising computer readable program 

means for causing a computer to effect maintenance of said * * * * * 
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